Method and System for Establishing a User-Friendly Data Transfer Service Application Executing Within a Heterogeneous Distributed Service Application Execution Environment

ABSTRACT

Various embodiments of the present invention are directed to methods and systems for data transfer between electronic, hand-held devices, including cell phones, and computer systems, including servers and PCs, as well as component methods and systems of these data-transfer methods and systems. Component methods and systems of the present invention include secure links between various devices, enhancements to electronic hand-held devices that enable service applications to run continuously or intermittently on the devices, deployment of dynamically created service applications to electronic, hand-held devices, and various additional component methods and systems that facilitate the above-mentioned component methods and systems. One embodiment of the present invention is a robust, efficient, secure, and user-friendly method and system for transferring data between cell phones and personal computers.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a division of U.S. patent application Ser. No.11/540,497, filed Sep. 28, 2006 and entitled “METHOD AND SYSTEM FORESTABLISHING A USER-FRIENDLY DATA TRANSFER SERVICE APPLICATION EXECUTINGWITHIN A HETEROGENEOUS DISTRIBUTED SERVICE APPLICATION EXECUTIONENVIRONMENT,” which claims the benefit of Provisional Application No.60/721,262, filed Sep. 28, 2005, the disclosures of which are herebyincorporated herein by reference.

TECHNICAL FIELD

The present invention is related to data transfer and data management inelectronic systems and, in particular, to a method and system forexecuting service applications in heterogeneous environments, includinga service application for securely transferring data between a widevariety of different types of electronic devices, with varyingcapabilities and capacities, interconnected by multiple communicationsmedia.

BACKGROUND OF THE INVENTION

In the early days of computing, data was transferred between computersby physically transferring the data encoded in physical media, includingpunch cards and, later, magnetic disk platters. With the advent ofsophisticated, high-bandwidth electronic communications media,data-transfer protocols, and various higher-level protocols, such asHTTP over TCP/IP, data transfer between various types of computersystems, including main frames, high-end servers, and PCs has becomeroutine and extremely economical. For example, during the span of asecond, enormous amounts of textual, graphical, audio, and video dataare transferred across the world between web servers and PCs via theInternet.

During the past ten years, there has been a spectacular increase in theavailability and use of wireless, hand-held electronic devices,including cell phones, email devices, personal digital assistants(“PDAs”), and other such devices. Although the sophistication andcapabilities of these small, hand-held devices have increasedsignificantly, they are still generally far less sophisticated, and havefar less computational power than, personal computers and computersystems. Moreover, these devices are generally interconnected throughdifferent communications infrastructures than those used to interconnectcomputer systems, although, in certain cases, both computers andhand-held electronic devices may be interconnected through commoncommunications media.

FIG. 1 illustrates a typical computer, hand-held-device, server, andcommunications environment. In FIG. 1, a high-end server system 102 isinterconnected with a remote personal computer (“PC”) 104 via theInternet 106. The Internet 106 transfers data packets through variousphysical communications media, including high-bandwidth optical lines,telephone lines, a variety of routing computer systems, and othercommunications media, including local networks and local wirelessnetworks, using a complex, hierarchically organized set of protocols.Cell phones 108 and 109 are connected through the phone network 110. Thephone network employs different protocols and different physicalcommunications media, although, as pointed out above, the phone networkand the Internet may share certain physical communications media.Communication between cell phones 108 and 109 via the phone network 110is robust, user-friendly, and extremely economical, just as datatransfer by file-transfer protocols, email, and Internet browserapplications through the Internet is extremely robust, user friendly,and economical. However, in many cases, data transfer and communicationbetween cell phones 108-109 and server computers 102 and PCs 104 isdifficult, not user friendly, time consuming, and relatively expensive.

FIG. 2 illustrates, using the illustration conventions of FIG. 1, ascenario in which economical and user-friendly data transfer from a cellphone to a personal computer would be desirable. As shown in FIG. 2, thecell phone 109 may be used to record a digital image of a scene 202 viaa digital camera commonly included within cell phones. However, mostcell phones have only limited capacity for storing these digital images,and currently, there are few practical services available fortransferring digital images from cell phones to other devices andsystems. It may be possible to physically transfer the image from cellphone 109 to PC 104 via a removable memory device, and it may also bepossible to transfer the digital image from cell phone 109 to PC 104using a physical cable for electronically interconnecting 204 the cellphone to the PC. Of course, while direct electronic connection throughcables requires that the cell phone be brought to the location of thepersonal computer, or vice-versa, it is often a relatively cumbersome,not-user-friendly, and slow procedure, involving loading specialsoftware, purchasing cables compatible both with the cell phone and thepersonal computer, and other such tasks. While removable memory-storagedevices can be used to store digital images transferred from the cellphone until the removable storage devices can be, in turn, physicallytransferred to the location of the personal computer, purchasingremovable storage devices with sufficient storage capacity that arecompatible both with the cell phone and the personal computer mayrepresent a challenge for many users, and removable storage devices maybe lost, damaged, or intermingled with other removable storage devicescontaining other types of data. It is also possible, in certain cases,to transmit digital images from the cell phone 109 to the phone network110, and from the phone network to the Internet 106 for final transferto a PC or server using specialized multimedia messaging protocols.However, acquiring access to such protocols may require installation ofapplications on the cell phone and relatively cumbersome data entry tothe cell phone in order to install the transferred applications and todirect transfer of digital images to a desired server or personalcomputer. Moreover, in many cases, the transfer is not secure, and maynot be reliable. The occurrence of various types of errors duringtransfer, for example, may result in loss of the digital image.

The difficulties associated with transferring digital images from cellphones to personal computers, from a first cell phone to a second cellphone, and difficulties associated with transferring other types of datafrom cell phones and other types of electronic, hand-held devices topersonal computers and remote electronic, hand-held devices are becomingmore noticeable and annoying to consumers as the capabilities ofelectronic, hand-held devices increase, and as consumers become morefamiliar with the existing, highly robust, and user-friendlydata-transfer systems for transferring data between and among personalcomputers and servers. Therefore, users, manufacturers, vendors, anddevelopers of cell phones and cell phone-related technologies have allrecognized the need for a more robust, user-friendly, efficient, andeconomical method and system for transferring data between cell phonesand computer systems, between various types of electronic hand-helddevices, from personal computers to electronic hand-held devices, andother such data transfers in heterogeneous environments.

BRIEF SUMMARY OF THE INVENTION

Various embodiments of the present invention are directed to methods andsystems for data transfer between electronic, hand-held devices,including cell phones, and computer systems, including servers and PCs,as well as component methods and systems of these data-transfer methodsand systems. Component methods and systems of the present inventioninclude secure links between various devices, enhancements to electronichand-held devices that enable service applications to run continuouslyor intermittently on the devices, deployment of dynamically createdservice applications to electronic, hand-held devices, and variousadditional component methods and systems that facilitate theabove-mentioned component methods and systems. One embodiment of thepresent invention is a robust, efficient, secure, and user-friendlymethod and system for transferring data between cell phones and personalcomputers.

One embodiment of the present invention is a method and system fortransferring images from a camera-equipped phone to a personal computerthrough a file server. The camera-equipped phone generates a digitalimage, for example by taking a digital photo with a built-in or attachedcamera, and transmits the digital image over a standard wirelessnetwork, for example the cellular GSM/GPRS network, to a file server.The personal computer is connected to the internet. The file server isconnected both to the standard wireless network and to Internet, andreceives digital images from a camera-equipped phone over the networkand transmits digital images to the personal computer through theInternet. Both the camera-equipped phone and the personal computer runan image-transfer software program, and use unique addresses to enablethe camera-equipped phone to direct images through the file server tothe personal computer.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, reference isnow made to the following descriptions taken in conjunction with theaccompanying drawings, in which:

FIG. 1 illustrates a typical computer, hand-held-device, server, andcommunications environment.

FIG. 2 illustrates, using the illustration conventions of FIG. 1, ascenario in which economical and user-friendly data transfer from a cellphone to a personal computer would be desirable.

FIG. 3 illustrates a high-level overview of one embodiment of thepresent invention.

FIG. 4 illustrates the capture of a digital image and secure, seamlesstransfer of the digital-image data from the cell phone to the personalcomputer according to one embodiment of the present invention.

FIG. 5 illustrates the conceptual, intercommunicating applications thattogether comprise one view of the virtual communications medium andnetwork that represents one embodiment of the present invention.

FIG. 6 illustrates intercommunication provided by the virtualcommunications medium and network.

FIGS. 7A-D illustrate, at overview level, the steps involved in creatingthe virtual communications medium and network (302 in FIG. 3) to allowfor peer-to-peer interaction between PC applications and cell phoneapplications.

FIG. 8 is a control-flow diagram for a routine “deploy” that representsone embodiment of the present invention.

FIG. 9 is a control-flow diagram for the routine “collectInformation”invoked in step 804 of the routine “deploy” shown in FIG. 8.

FIGS. 10A-D describe one embodiment of the target-device identificationstep 806 of the routine “deploy” shown in FIG. 8.

FIG. 11 is a control-flow diagram illustrating the routine “createDCA”called from step 808 of FIG. 8.

FIGS. 12A-B include control-flow diagrams that describe the delivery ofDCAs to target devices invoked in step 810 of FIG. 8.

FIG. 13 shows a control-flow diagram for the routine “installDCAs”invoked in step 812 of FIG. 8.

FIG. 14 illustrates the meaning of the terms “service application,”“client,” and “function” with respect to embodiments of the presentinvention.

FIG. 15 illustrates a set of relational tables that may be used to storeinformation related to service-application and client deploymentinstallation on target devices according to one embodiment of thepresent invention.

FIG. 16 is a control-flow diagram illustrating a routine that determinesthe minimal set of clients to add to a target device in the course ofdeploying a service application, called in step 1120 of the routine“createDCA” described in FIG. 11.

FIG. 17 provides a control-flow diagram for a remove-service-applicationroutine.

FIG. 18 illustrates the concept of a link.

FIG. 19 illustrates implementation of the link shown in FIG. 18.

FIG. 20 illustrates establishment of a link according to method andsystem embodiments of the present invention.

FIG. 21 illustrates establishment of a secure link between a clientrunning on a device and a server according to one embodiment of thepresent invention.

FIG. 22 illustrates a number of the possible methods by whichinterprocess communication can be implemented in an electronic,hand-held device in communication with a server when the electronic,hand-held device does not offer native interprocess communications,according to method and system embodiments of the present invention.

FIG. 23 displays various methods for implementing persistent datastorage on an electronic, hand-held device, when persistent data storagefacilities are not explicitly provided by the device according to methodand system embodiments of the present invention.

FIG. 24 illustrates a number of mechanisms that can be used forlaunching and reawakening processes within an electronic, hand-helddevice according to method and system embodiments of the presentinvention.

FIG. 25 is a control-flow diagram illustrating process behavior on anelectronic, hand-held device for processes that cooperate to implement arobust, multi-tasking environment according to method and systemembodiments of the present invention.

FIG. 26 illustrates a digital-image-transfer service application thatrepresents one embodiment of the present invention.

FIG. 27 is a control-flow diagram illustrating operation of thesource-device portion of the digital-image-transfer service applicationthat represents one embodiment of the present invention.

FIGS. 28 and 29 illustrate the server portion of the digital-imagetransfer service that represents one embodiment of the presentinvention.

FIG. 30 is a control-flow diagram illustrating the target-device portionof the digital-image transfer service application that represents oneembodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is directed to methods and systems for robust,efficient, secure, and user-friendly data transfer between electronic,hand-held devices and personal computers. The present invention isdescribed, below, in the context of a method and system for transferringdigital-image data from cell phones to personal computers, personalcomputers to cell phones, and between cell phones, but the presentinvention is directed to a much broader and more general transfer methodfor transferring many different types of data between many differenttypes of electronic devices, as well as for establishing aservice-application environment and virtual communications medium andnetwork to support the data-transfer application. In a first subsection,below, an overview of one approach to transferring data betweenelectronic hand-held devices and personal computers is provided. Insubsequent subsections, individual component methods and systems thatenable implementation of the data-transfer method and system outlined inthe first subsection are discussed, in detail, with reference tocontrol-flow diagrams and other technical presentations. In a finalsubsection, a more detailed discussion of the exemplary data-transfermethod and system outlined in the first subsection is provided.

Overview of a Data-Transfer Method and System that Represents OneEmbodiment of the Present Invention

FIG. 3 illustrates a high-level overview of one embodiment of thepresent invention. FIG. 3 uses the same illustration conventions as usedin FIGS. 1 and 2. In FIG. 3, the server system 102, PC 104, and cellphones 108 and 109 are shown to be linked, and in communication with oneanother, through a virtual communications medium and network 302. At thehighest level, the present invention is directed to creating a virtualcommunications medium and network 302 that allows personal computers,servers and main frame computers, cell phones, and other electronic,hand-held devices to intercommunicate efficiently, reliably,economically, and securely. At a second level, method and systemembodiments of the present invention are directed to serviceapplications that execute in the context of the virtual communicationsmedium and network to provide for data transfer, including transfer ofdigital images. FIG. 4 illustrates the capture of a digital image andsecure, seamless transfer of the digital-image data from the cell phoneto the personal computer according to one embodiment of the presentinvention. A user can transfer a digital image, for example, from theuser's cell phone to the user's personal computer automatically, withoutuser intervention, or via any number of user interfaces as intuitive andeasy to use as those employed to connect a first cell phone to secondcell phone through the phone network.

The virtual communications medium and network (302 in FIG. 3) createdaccording to one embodiment of the present invention may make use of thephone network, the Internet, a variety of different physicalcommunications media, protocols, and other complex layers of softwareand hardware. It would be impossible to describe, in detail, theorganization and operation of all of these communications media andsoftware and hardware layers in this document, and such a description isunnecessary, since these communications media, software layers, andhardware layers are generally well known to those skilled in the art ofcommunications, cell phones, and computer systems. Rather than viewingthe virtual communications medium, or network, as a complex,multi-layered combination of existing technologies, software, hardware,and communications media, it is conceptually easier to view the virtualcommunications medium as a collection of intercommunicating applicationsor as one or more distributed applications. FIG. 5 illustrates theconceptual, intercommunicating applications that together comprise oneview of the virtual communications medium and network that representsone embodiment of the present invention. As shown in FIG. 5, the virtualcommunications medium 302, and interfaces supported by the virtualcommunications medium, can be viewed as a separate, intercommunicatingserver application 502, a PC application 504, and cell phoneapplications 506 and 508. Alternatively, these separate,intercommunicating applications can be viewed as a single distributedservice application composed of device-side and server-side serviceapplications.

FIG. 6 illustrates intercommunication provided by the virtualcommunications medium and network. As shown in FIG. 6, PC applications,cell phone applications, and server applications can transfer data amongone another via the virtual communications medium, with the server andserver application 502 acting as a central switch through which datatransfers are routed. Unlike in current environments, as shown in FIGS.1 and 2 and described in a previous section, the virtual communicationsmedium created according to the present invention allows PC applicationsand cell phone applications to intercommunicate as peers, with both PCapplications and cell phone applications providing user-friendlyinterfaces, when user-interfaces are desired.

FIGS. 7A-D illustrate, at overview level, the steps involved in creatingthe virtual communications medium and network (302 in FIG. 3) to allowfor peer-to-peer-like interaction between PC applications and cell phoneapplications or within a distributed service application. First, asshown in FIG. 7A, a PC user interacts with a server application 502running on a server system to download the PC application to the PC.Once downloaded, as shown in FIG. 7B, the PC can be viewed, at highlevel, as a PC application 504. Next, as also shown in FIG. 7B, a PCuser interfaces with the PC application to direct the server applicationto deploy a service on a particular cell phone 702. Then, as shown inFIG. 7C, the server application 502 communicates with the cell phone 702in order to determine the type of cell phone and other parametersrelated to, and characteristics of, the cell phone. Then, as shown inFIG. 7D, the server application 502 creates an initial cell phoneapplication and transfers the initial cell phone application to the cellphone 704. The cell-phone application is preconfigured with accountcredentials to facilitate subsequent communication with the PC andserver, so that subsequent configuration of the cell-phone applicationis not necessary. The initial cell phone application is launched, eitherautomatically or by a separate signal sent from the server application,and transforms the cell phone into a multi-tasking cell phoneenvironment 706 in which the cell phone application can run as a serviceapplication. Once the cell-phone application is running as a serviceapplication, the cell-phone application can communicate with both theserver application 502 and PC application 504 in a peer-to-peer-likefashion, as illustrated in FIGS. 5 and 6.

Dynamically Created Service Application

As discussed in the previous section, with reference to FIGS. 7C-D, animportant step in configuring the virtual communications medium andnetwork (302 in FIG. 3) that allows for secure, robust, anduser-friendly intercommunication between cell phones, servers, and PCsis deployment of a service application specifically tailored for thehand-held electronic device, in the context of a user-requested servicerelated to the electronic, hand-held device. Deployment of dynamicallycreated service applications (“DCAs”) is described in the currentsubsection. It should be noted that, while a specific embodiment of thepresent invention is discussed in this subsection, and in subsequentsubsections, there are a myriad of alternative embodiments that can beimplemented according to the present invention within the large varietyof different contexts for which service applications intercommunicatingthrough a virtual communications medium and network can be crafted andconfigured. Although, in the following discussions, the steps undertakento accomplish various tasks and subtasks are presented in particularorders, many of the steps may be alternatively carried out in differentorders, depending on implementation strategies and the context of theproblem domain addressed by the implementations. A description of one ora few embodiments of the present invention may address only a smallsubset of the possible techniques and strategies for accomplishing theset of tasks which together comprise the goals and specification for animplementation of the present invention. Thus, the following descriptionof particular embodiments of the present invention is in no way intendedto limit the scope of implementations and strategies that may beundertaken according to the present invention.

FIG. 8 is a control-flow diagram for a routine “deploy” that representsone embodiment of the present invention. The control-flow diagram ofFIG. 8 provides a highest-level overview of a DCA creation anddeployment method of the present invention. In step 802, the routine“deploy,” running on a server in the described embodiment, receives arequest from a user device, typically a PC, to deploy a particularservice to a different user device, such as a cell phone. In general, aparticular user requests deployment of services to electronic devicesowned and controlled by the user, although, in more general cases,service applications may be deployed to electronic devicesautomatically, at the request of third parties, or in response toalternative types of invocations. When deployment is requested toelectronic devices by third parties, or to electronic devices not ownedor controlled by the requester, various techniques and strategies may beemployed to ensure that services are deployed only with the implicit orexplicit permission and authorization of the device owners and/or users.

In step 804, the routine “deploy” collects information from therequester and, optionally, from additional users identified in therequest, needed for establishing and configuring the requested servicewith respect to the target electronic devices. In step 806, the routine“deploy” undertakes a process to identify and characterize each targetdevice to which the service application is to be deployed. In step 808,the routine “deploy” creates a DCA for each target device. Serviceapplications are dynamically created for each target device in order to,at the least, incorporate target-device-specific information into eachservice application, and, more generally, to tailor the serviceapplication for the specific target device. In step 810, the routine“deploy” delivers the DCAs created in step 808 to their respectivetarget devices. Finally, in step 812, the routine “deploy,” whennecessary, undertakes installment of the delivered DCAs within theirrespective target devices. These final two steps are commonly combinedand interleaved, but are shown separately in FIG. 8 for conceptualclarity.

FIG. 9 is a control-flow diagram for the routine “collectInformation”invoked in step 804 of the routine “deploy” shown in FIG. 8. In step902, the routine “collectInformation” determines the users for whichdeployment of a service application is undertaken. In the most commoncase, a single user requests deployment of a service to one or more ofthe user's electronic devices, but, in a more general case, the requestmay specify deployment of a service for a set of users. The users may befully identified in the request received in step 802 of FIG. 8, or maybe only partially identified, requiring the routine “collectinformation” to access additional information sources or to furtherinteract with the requester in order to fully identify all users ofdevices to which the service application is to be deployed. In thefor-loop of steps 904-912, the routine “collectInformation” collectsneeded user and user-device information for each user identified in step902. In step 905, the routine “collectInformation” collects sufficientinformation to identify the currently considered user. In this step, forexample, the routine “collectInformation” may query a user orapplication running on a user's PC for information needed to identifythat the user or user application is the user for which deployment isrequested. Queries may involve request and receipt of passwords, useridentifiers, and other information that may be matched to previouslyacquired information stored by the server on which the routine“collectInformation” runs, and may alternatively involved a wide varietyof other user-identification techniques, including biometric analysis ofuser-supplied data, or alternative methods of identifying the user.

Next, in step 906, the routine “collectInformation” may collectadditional user-related information, including the PC network addressfor the user's PC, the user's email address, billing information, if thebilling information has not been previously stored, characteristics andcapabilities of the user's PC or other device, and other suchinformation. If the user is not the entity requesting deployment, asdetermined in step 907, then the routine “collectInformation” mayoptionally request permission of a user for deployment of the serviceapplication to the user's devices in steps 908 and 909. Next, in step910, the routine “collectInformation” determines the target devices forthe currently considered user to which the service application is to bedeployed. This information may be included in the request received instep 802 of FIG. 8, or may involve additional queries or access topreviously stored information. In step 911, the information collectedfor the user and for the user's target devices is stored in auser/target list that directs creation and deployment of DCAs insubsequent steps of the routine “deploy.”

FIGS. 10A-D describe one embodiment of the target-device identificationstep 806 of the routine “deploy” shown in FIG. 8. FIG. 10A is acontrol-flow diagram for the routine “identifyTargetDevices” called instep 806 of FIG. 8. The routine “identifyTargetDevices” comprises afor-loop of steps 1002-1007 in which each target device included in theuser/target list prepared in step 911 of FIG. 9 is identified andcharacterized. In step 1003, the user-supplied informationcharacterizing the currently considered target device is transformedinto an address and putative device type, generally by accessing storedinformation concerning general device types, device-related information,and perhaps specific information regarding the devices owned and used byusers previously collected and compiled by the server. Certain datatables that can facilitate this step are discussed in a subsequentsubsection. Then, in step 1004, the routine “identifyTargetDevices”sends a reference, such as a URL, to the target device, in certain casesin the form of an installation message. When the installation message isreceived by the target device, a prompt may be displayed on the targetdevice that, when accepted or acknowledged by a user of the targetdevice, or automatically, generates a request directed to the reference,such as a URL, that is received and processed by the server. Thedevice's response to the installation message is then used by theserver, as described below, to identity the type of device andcharacterize the device. In step 1005, the routine“identifyTargetDevices” notes that an installation message was sent tothe target device and sets a retry count for the target device to 0. Ingeneral, the routine “identifyTargetDevices” stores a record indicatingthat the installation message was sent in memory or in a database. Then,in step 1006, the routine “identifyTargetDevices” sets a timer for theinstallation message, in order to detect failure of the target device torespond, as described subsequently.

FIGS. 10B-C show a control-flow diagram for a handler that continuouslyexecutes on the server to handle events associated with theabove-described routine “identifyTargetDevices.” In step 1010, thehandler waits for a next event. When a next event occurs, the handlerawakens and, in step 1012, associates a particular target device andstored state information related to that target device with the event.If the event is a response to an installation message sent in step 1004of FIG. 10A, as determined in step 1014, then, in step 1016, the handlerinvokes a routine to determine the type of device and characterize thedevice from the request/response message sent by the target device inresponse to the installation message. If the device type can bedetermined and the device fully characterized from the request/responsemessage, as determined in step 1018, then the device type and devicecharacterization is stored in memory, and the state informationassociated with the target device is deleted, in step 1020, completingidentification and characterization of the target device.

Otherwise, in step 1022, the handler selects a probe application for thedevice and transmits the probe application to the target device. A probeapplication is selected based on the best guess as to the type of devicethat can be made based on the response/request message received from thedevice and any other device information previously accessed andassociated with the target device. If, in addition to sending the probeapplication, a separate installation message or signal needs to be sentby the handler in order to launch or invoke the probe application on thetarget device, as determined in step 1024, then, in step 1026, thehandler transmits the installation message or signal to the targetdevice following a sufficient period of time for the transmitted probeapplication to be received and processed by the target device. Ratherthan waiting for the needed period of time, the handler may simplytransmit the probe application, in step 1022, and then set a timer tosubsequently reawaken the handler for transmitting the installationmessage or signal. Next, in step 1028, the handler sets a timerassociated with deployment of the probe application to the target deviceand, in step 1029, records the fact that the probe application was sentto the target device and sets a retry counter to 0, in step 1029. If theevent that awakened the handler is a response to a probe installation,as determined in step 1030, then, in step 1032, the handler invokes aroutine to determine the type of the target device and characterize thetarget device based on a message received from the executing probeapplication. If, as determined in step 1034, the type of device is fullydetermined and the device sufficiently characterized based on theprobe-application message, then, in step 1036, the device type andcharacterization is stored in memory, and state information associatedwith the target device is deleted. Otherwise, in step 1038, the failureto identity the device from the probe information is noted in memory.If, as determined in step 1040, there is another probe application thatmay be sent to the target device to attempt to identify the type of thetarget device, the next probe application is selected and transmitted tothe target device in step 1042, and control flows to previouslydescribed step 1024 for installation of the transmitted probeapplication and setting of a timer associated with transmission of theprobe application. If no additional probe application can be sent to thetarget device, then, in step 1044, the failure to identify orcharacterize the target device is recorded, and target deviceinformation is removed from the user/target list to prevent additionalservice-application-deployment steps directed to the target device.Various different types of actions may be taken, upon failure toidentify and characterize the target device, in differentimplementations of the DCA creation and deployment method of the presentinvention.

If, as determined in step 1046, the event that wakened the handler is anexpiration of a timer associated with a transmission of a firstinstallation message, then, in step 1048, the handler determines thenumber of times that target identification has been tried. If the numberof attempts to identify the device exceeds a maximum threshold value, asdetermined in step 1050, then complete failure to identify andcharacterize the device is noted in step 1052, and the target device isremoved from the user/target list prepared in step 911 in FIG. 9.Otherwise, a new message containing a reference is sent to the targetdevice in a new installation message, in step 1054, the retry counter isincremented in step 1056, and the timer for the installation message isreset in step 1058. If the event that awakened the handler is expirationof a timer associated with a probe application, as determined in step1060, then in step 1062, the handler determines the number of times thatprobe application has been tried on a target device. If the number oftimes that the probe application has been tried exceeds a maximumthreshold value, as determined in step 1064, then a complete failure isnoted, and the target-device information is removed from the user/targetlist in step 1066. Otherwise, the last transmitted probe application isretransmitted to the target device, in step 1066, and additional stepsfor launching the probe application, resetting of theprobe-application-related timer and updating the retry counter arecarried out in steps 1068-1071. Otherwise, any other event that awakenedthe handler is handled in a default handler routine of step 1072. In allcases, following handling of the event that awakened the handler,control returns to step 1010, where the handler waits for a next event.

The handler implementation is somewhat simplified, in FIGS. 10B-C, tofacilitate description of the present invention. In general, handlersmay be designed to handle multiple events that may occur concurrentlywhile the handler is active, rather than being explicitly invoked foreach separate event. However, general construction and implementation ofhandlers is well known, and such details would serve only to obscure theessence of the present invention.

FIG. 10D is a control-flow diagram that generally describesidentification and characterization of a target device from arequest/response message received from an initial installation messageor from a probe application, in steps 1016 and 1032 of FIG. 10B. Incertain embodiments of the present invention, separatedevice-identification routines may be implemented for steps 1016 and1032 of FIG. 10B, while in alternative embodiments, a commondevice-identification routine may be invoked from either of steps 1016and 1032. In step 1080, the routine “determineDeviceType” determineswhether the request/response message was returned by a probeapplication. If so, then in step 1082, the routine “determineDeviceType”determines whether an explicit type was included in the message receivedfrom the probe application. If so, then in step 1084, the explicitdevice type is returned, along with any additional information relatedto characterization of the device. Certain types of probe applicationsmay invoke functions on the target device to determine the device type.Alternatively, probe applications may access various functions andfeatures of a target device and determine the type of the target devicebased on the behavior of the target device. However, if the message isnot returned by a probe, or does not include explicit type information,then, in step 1086, the routine “determineDeviceType” extractstype-related information from the request/response message header orheaders. Often, headers in messages sent from a target device includesufficient information to infer the type of the target device. In step1088, when necessary, the routine “determineDeviceType” extracts anytype-related information that can be gleaned from the request/responsemessage body. Then, in step 1090, the routine “determineDeviceType”applies a set of rules to the information extracted in steps 1086 and1088 to determine and characterize the target device based on theextracted information. If application of the rules to the extractedinformation unambiguously determines a device type, and furthercharacterizes the device, as determined in step 1092, then the devicetype and additional characterization is returned in step 1094.Otherwise, failure to determine the device type is determined in step1096.

FIG. 11 is a control-flow diagram illustrating the routine “createDCA”called from step 808 of FIG. 8. The routine “createDCA” is essentiallytwo nested for-loops, beginning in steps 1102 and 1104, in which a DCAis created for each target device for each user described in theuser/target list prepared in step 911 of FIG. 9. If source code needs tobe compiled or assembly code assembled for the DCA, as determined instep 1106, then the source code is compiled and/or assembly codeassembled in step 1108. Thus, dynamic creation of a service applicationmay involve on-the-fly compilation or assembly, to enable particularsource code or assembly code suitable for the target device to becollected and compiled and/or assembled with particular compiler flagsand assembler flags and parameters suitable for the target device. If,as determined in step 1109, existing executables need to be modified tocreate a DCA tailored for the target device, as determined in step 1109,then the executables are accordingly modified in step 1110.Modifications may include renaming the executables, or it may includealtering data sections contained in the executables, changing headers ofthe executables, or other such modifications. If, as determined in step1112, additional executables need to be identified and collected inorder to prepare a DCA specifically targeted to the currently consideredtarget device, as determined in step 1112, then the additionalexecutables are located and collected in step 1114. The executables,modified executables, and on-the-fly compiled and/or assembledexecutable code obtained in steps 1108, 1110, and 1114 are assembledtogether to produce an executable service application tailored for thecurrently considered target device in step 1116. The product of step1116 may be a single executable, a single executable with additionallibrary routines, a set of executables, or other forms of executableservice applications suitable for the currently considered targetdevice.

Next, in step 1118, the routine “createDCA” determines whetheradditional clients need to be activated for provision of particularfunctions on the target device, transmitted to, and installed on, thetarget device, or otherwise invoked on the target device. Clients areexecutables or libraries that provide a set of well-defined functionsthat can be called by one or more service applications, and may beseparate entities or embedded in service applications. If additionalclients need to be transmitted to, or activated on, the target device,then, in step 1120, the minimal set of clients that need to betransmitted to, or activated on, the target device is determined. Theclients may be included in the DCA or separately transmitted to, andinstalled on, the target device.

Next, in step 1122, the routine “createDCA” determines whetheradditional data needs to be included in the DCA. If so, then, in step1124, the routine “createDCA” determines whether any of the additionaldata needs to be transformed into executable code. If so, then thatportion of the additional data that needs to be transformed intoexecutable code is so transformed in step 1126. For example, the DCA mayneed to access data describing a screen layout or menu that forms partof a user interface for the service application on the target device.The data may be explicitly included in the DCA, or executable code maybe included in a DCA to generate the data when executable code isexecuted on the target device. In step 1128, the routine “createDCA”determines whether any additional data needs to be appended to the DCA.If so, then that additional data is appended to the DCA in step 1130. Instep 1132, the routine “createDCA” determines whether the DCA requiresreferences, such as URLs, to data stored remotely from the targetdevice. If so, then those references to remotely stored data are addedto the DCA in step 1134. Thus, data needed by the service application onthe target device may be transmitted for storage on the target device,generated by executables running on the target device, or accessed bythe service application from remote data sources during execution of theservice application on the target device. In step 1136, the assembledexecutables generated in step 1116 are packaged together with the addedreferences, data, and data-generating executables produced in steps1126, 1130, and 1134 to produce a final DCA. If the DCA needs to besigned and/or encrypted, as determined in step 1138, then the DCA isdigitally signed and/or encrypted in step 1140. A wide variety ofdifferent digital signing and encryption techniques, includingpublic/private encryption key-based techniques, can be employed toensure that a DCA created and tailored to a particular target devicecannot be intercepted and used by another device.

FIGS. 12A-B include control-flow diagrams that describe the delivery ofDCAs to target devices invoked in step 810 of FIG. 8. FIG. 12A shows acontrol-flow diagram for a routine “deliverDCA.” The routine“deliverDCA” is a for-loop, beginning with step 1202, that delivers theDCA prepared for each target to its corresponding target device. Notethat, in the described embodiment, all DCAs are prepared for targetdevices prior to delivery of the DCA to their respective target devices,although in alternative embodiments, steps 808 and 810 of FIG. 8 may beinterleaved so that the DCA is immediately delivered to its targetdevice prior to preparation of subsequent DCAs for subsequent targetdevices. In step 1204, the DCA prepared for the currently consideredtarget device is selected. If the DCA is to be delivered electronically,as determined in step 1206, then, in steps 1208-1212, a download messageis sent to the target device to direct the target device to download theDCA from the server, in step 1210, in the case that a pull paradigm isappropriate for the target device, or, otherwise, the DCA is sent in oneor more messages to the target device in step 1211 and, in either case,download or transmission of the DCA is noted, in memory in step 1212. Ifthe DCA is not delivered electronically, then the DCA may be physicallydelivered, in step 1214, with physical delivery of the DCA noted inmemory in step 1216. Determination of whether or not to electronicallydeliver the DCA, in step 1206, may be made based on characteristics ofthe target device, pre-collected user preferences, or other suchinformation. Electronic delivery may occur through the phone network,the Internet and the phone network, or through cables or other directconnections between the target device and the server or a PC incommunication with the server. Physical delivery of the DCA may occur byencoding the DCA on a data storage medium, such as a CD, DVD, memorystick, or other such data-storage medium, and physically transportingthe data-storage medium to a user of the target device via mail orpackage-delivery services.

FIG. 12B shows a handler associated with the routine “deliverDCA.” Instep 1220, the handler waits for a next event associated with DCAdelivery. When that event occurs, the handler looks up DCA informationrelated to that event in step 1222. If the event is a timer expiration,as determined in step 1224, then the handler accesses retry counterinformation in the DCA information associated with the event, in step1126. If delivery has already been tried a maximum number of times, asdetermined in step 1228, then the DCA information is deleted from theserver, and failure to deliver is noted, in step 1230. Otherwise, theDCA is retransmitted to the target device, in steps 1232-1234, the timeris reset in step 1236, and the retry counter is updated in step 1238. Ifinstallation is not automatic, as determined in step 1240, then in step1242, the handler sends an appropriate installation message or signal tothe target device. In alternative embodiments, sending of installationmessages and signals occur in response to an additional event, such asexpiration of a timer, set by the handler, rather than a handler waitingfor delivery of the DCA. If the event is a reception of adelivery-complete message, as determined in step 1244, then the DCAinformation associated with the event is deleted from server memory, andinstallation data tables are updated to reflect successful deployment ofthe DCA to the target device, in step 1246.

If the event corresponds to reception of an improper installationmessage, as determined in step 1248, then the improper installationproblem is diagnosed, in step 1250. In certain cases, as determined instep 1252, installation may be retried, while in other cases, DCAdeployment is considered to have failed, and the DCA informationassociated with the event is deleted from memory and the failure noted,in step 1254. Any other events are handled by a default event handler instep 1256. In the described embodiment, the handler waits to receive adelivery-complete message from the target device for considering the DCAto be successfully deployed. In alternate embodiments, the “deliverDCA”routine may explicitly inquire, via messaging or other means, whetherthe target device has received and successfully deployed the DCA.

FIG. 13 shows a control-flow diagram for the routine “installDCAs”invoked in step 812 of FIG. 8. This routine sends an explicitinstallation message or signal to target devices that requireinstallation messages or signals to invoke installation of a deployedDCA. The installation messages or signals may alternatively be sent bythe routine “deliverDCA” shown in FIG. 12A, or may be sent from the DCAhandler, as shown in FIG. 12B, following expiration of a timer set bythe routine “deliverDCA” to allow for a reasonable amount of timebetween transmission of the DCA to the target device and installation.

Next, the method for determining the minimal set of clients to add to aDCA, a routine for which is invoked in step 1120 of FIG. 11, isdescribed with reference to FIGS. 14 and 15, exemplary SQL-likepseudocode, and two control-flow diagrams provided in FIGS. 16 and 17.FIG. 14 illustrates the meaning of the terms “service application,”“client,” and “function” with respect to embodiments of the presentinvention. In FIG. 14, a server 1402 and target device 1404 are shown asblocks. A service application that provides for a service accessed fromthe target device can be considered to be distributed between the serverand target device, with a server-side service-application portion 1406executing on a server and a device-side service-application portion 1408executing on the target device. The device-side service application mayinvoke functions provided by one or more clients that execute on thetarget device. A client may be embedded within a service application,such as embedded client 1410, may be independent executable entitiesthat run on the target device, such as client 1412, or may be embeddedin a different service application from the service application thatinvokes functions provided by the client, such as embedded client 1414in FIG. 14. Clients are analogous to shared library routines accessed byprograms executing on a personal computer.

Many hand-held electronic devices have limited memories and limitedcomputational capacities. In these devices, it is important to installonly as many clients as needed by the services currently deployed to thetarget device and by the native target-device control program andapplication. Thus, when a DCA is deployed to a target device, method andsystem embodiments of the present invention endeavor, in step 1120 ofFIG. 11, to deploy and activate a minimal set of clients needed fordeployment of a service application to the target device.

There are many different ways to monitor deployment and activation ofclients and functions provided by clients on target devices, and todetermine a minimum set of additional clients and function activationsneeded for deployment of a particular service application. In oneembodiment, information related to deployment of service applicationsand clients to target devices is maintained in a set ofrelational-database tables on a server, which are used in order todetermine a minimal set of client deployments and client-functionactivations needed during deployment of a service application, in step1120 of FIG. 11.

FIG. 15 illustrates a set of relational tables that may be used to storeinformation related to service-application and client deploymentinstallation on target devices according to one embodiment of thepresent invention. The table Services 1502 stores information related toservices deployed on target devices, including a service_ID,service_type, and service_location field for each deployed serviceapplication. Similarly, the table Clients 1504 and the table Functions1506 store information regarding deployed clients and functions providedby clients. The table Functions_Provided 1508 storesclient_ID/function_ID pairs indicating those functions provided by eachclient, and the table Functions_Needed 1510 storesservice_ID/function_ID pairs that indicate the particular functionsneeded by each different service application. The tableService_Client_Compatibility 1512 stores service_ID/client_ID pairs thatindicate which clients are compatible with which service applications,and the table Sharable 1514 stores service_ID/client_ID pairs thatindicate clients that may be sharable with respect to particular serviceapplications. The table Users 1516 includes information about eachdifferent user, including a user_ID, user_name, and additional userinformation fields. The table Devices 1518 describes each devicecontrolled or owned by users known to the system. The tableDevice_Client_Compatibility 1520 stores device_type/client_ID pairs thatindicate which clients are compatible with which device types, and thetable Device_Service_Compatibility 1522 stores device_type/service_IDpairs that each indicates that a service is compatible with a devicetype. The table Installed_Services 1524 includes device_ID/service_IDpairs that describe which service applications are installed on whichdevices, the table Installed_Clients 1526 stores device_ID/client_IDpairs that describe which clients are installed on the various devicesknown to the system. Finally, the table Active_Functions 1528 storesdevice_ID/client_ID/function_ID triples that describe functionsactivated for each client on each target device.

FIG. 16 is a control-flow diagram illustrating a routine that determinesthe minimal set of clients to add to a target device in the course ofdeploying a service application, called in step 1120 of the routine“createDCA” described in FIG. 11. Various steps in FIG. 16 areillustrated with SQL-like pseudocode. In the SQL-like pseudocode, thevariables S and T are defined as follows:

S=service_ID of service to be installed

T=device_ID of target device.

First, in step 1602, the routine determines the functions that areneeded by the service application to be deployed. SQL-like pseudocodefor this step, using the relational tables shown in FIG. 15, is nextprovided:

CREATE TABLE F (function_ID INTEGER) INSERT INTO F   SELECT DISTINCTfunction_ID   FROM Functions_Needed   WHERE service_ID = S.

If there are no functions needed, as determined in step 1604, then anindication that no clients need to be added is returned, in step 1606.Next, in step 1608, the routine determines which of the needed functionsare provided by compatible clients already installed on the targetdevice. SQL-like pseudocode for this step is next provided:

CREATE TABLE A (function_ID INTEGER) INSERT INTO A   SELECT Client_ID,function_ID   FROM Installed_clients I, Functions_Provided P,    Service_Client_Compatibility C, Sharable SB, F WHERE I.client_ID =P.client_ID   AND I.device_ID = T   AND C.service_ID = S   ANDC.client_ID = P.client_ID   AND SB.service_ID = S   AND SB.client_ID =P.client_ID   AND P.function_ID IN     (SELECT function_ID     FROM F)  GROUP BY function_ID.

In step 1610, the functions already provided by compatible clients,determined in step 1608, are subtracted from the functions needed by theservice application, determined in 1602, to produce a final list offunctions needed on the target device for the service application.SQL-like pseudocode for this step is next provided:

DELETE FROM F WHERE function_ID IN   (SELECT DISTINCT function_ID   FROMA).

Next, in step 1612, the routine determines whether any of thealready-available functions, determined in step 1608, need activation.Those functions needing activation are noted in a list of neededfunction activations in step 1614 that are eventually returned to theroutine “createDCA.” SQL-like pseudocode for determining functions thatneed activation is next provided:

DELETE FROM A WHERE function_ID IN   (SELECT DISTINCT function_ID   FROMActive_Function   WHERE device_ID = T   AND client_ID IN     (SELECTDISTINCT client_ID     FROM A).

If functions are still needed on the target device, as determined instep 1616, then, in step 1618, the routine determines a set of candidateclients that provide the needed functions. SQL-like pseudocode for thisstep is next provided:

CREATE TABLE CANDIDATES (client_ID INTEGER, function_ID INTEGER );INSERT INTO CANDIDATES SELECT DISTINCT client_ID, function_ID FROMFunctions_Provided P, Service_Client_Compatibility C,Device_Client_Compatibility D, Devices DS, Sharable SB, F WHEREP.client_ID = C.client_ID AND C.service_ID = S AND D.device_type =DS.device_type AND D.client_ID = P.client_ID AND DS.device_ID = T ANDP.client_ID = SB.client_ID AND SB.service_ID = S AND P.function_ID IN  (SELECT function_ID   FROM F) GROUP BY client_ID DESC.

If a single candidate client can provide all the needed functions, asdetermined in step 1620, then a single candidate client is selected fromall candidate clients that provide all the needed functions in step 1622and added to the return list. SQL-like pseudocode for obtaining a listof candidate clients that provide all of the needed functions is nextprovided:

SELECT COUNT (*) FROM F INTO Z; SELECT CD.client_ID FROM CANDIDATES CDWHERE Z =   (SELECT COUNT (DISTINCT function_ID)   FROM CANDIDATES CT  WHERE CT.client_ID = CD.client_ID).

Otherwise, in the for-loop of steps 1622-1625, possible combinations oftwo, three, and greater numbers of candidate clients are considered todetermine the minimal number of candidate clients necessary to provideall the needed functions. Once a suitable candidate combination isfound, that client combination is returned in step 1624. If nocombination of clients can be found to provide the needed functions,then failure is returned in step 1626. The list returned by the routineto the routine “createDCA” can then be used by the routine “createDCA”to include clients and instructions for function activation of existingclients into the DCA, to undertake explicit function-activation stepswith respect to the target device, and/or other steps in order to ensurethat the minimal set of clients as needed by the service application isinstalled on the target device and that the needed functions areactivated.

In certain embodiments of the present invention, a user may invoke amethod for removing a service application from a target device, or themethod may alternatively be automatically invoked by the user's PC orthe server under certain circumstances. FIG. 17 provides a control-flowdiagram for a remove-service-application routine. In step 1702, theroutine determines those functions needed by the service applicationthat is to be removed. In step 1704, the routine determines which ofthose functions needed by the service application to be removed areneeded by other applications that remain on the target device. Usingthis information, the routine determines, in step 1706, the functionsthat are no longer needed on the target device once the serviceapplication to be removed is removed from the target device and, in step1708, deactivates those unneeded functions by whatever techniques areappropriate for deactivating functions on the target device. If, asdetermined in step 1710, any clients on the target device have allfunctions provided by the clients deactivated, and are thereforeunneeded on the target device, then those clients are deleted from thetarget device in step 1712. Finally, in step 1714, the serviceapplication is marked for deletion or deleted from the target device.Thus, by maintaining only a minimal set of clients on a target deviceneeded by the service applications currently deployed to that targetdevice, the present invention minimizes the memory and computationalresources devoted to service applications on target devices so thattarget-device performance is minimally impacted by the serviceapplications, and so that a maximum number of service applications maybe deployed to the target device.

Link-Based Inter-Device Communication

As discussed in previous subsections, with particular reference to FIG.6, method and system embodiments of the present invention provide avirtual communications medium and network that allows electronichand-held devices, servers, and PCs to intercommunicate securely andrelatively seamlessly, from the standpoint of users. Thisintercommunication, however, is implemented within the currentlyexisting environment, such as the communications environment illustratedin FIG. 1. The virtual communications medium and network provided bymethod and system embodiments of the present invention is based on theestablishment of links between devices. FIG. 18 illustrates the conceptof a link. In FIG. 18, a first device 1802 communicates with a seconddevice 1804 via a link 1806. The link is shown traversing the server1808, since, as discussed above, the server, or servers inmultiple-server systems, acts as a switch for routing messages and. databetween devices. FIG. 19 illustrates implementation of the link shown inFIG. 18. The link is composed of a first two-way secure connection 1902between the first device 1802 and the server 1808 and a second secureconnection 1904 between a second device 1804 and the server 1808. Thelink is a logical entity, and may persist logically despite destructionand re-establishment of secure connections. Each device is associatedwith a global, unique ID 1906 and 1907 that allows devices to identifythemselves to the server and to other devices. The server maintains amapping of devices to IDs 1908 as well as a link table 1910 thatdescribes all currently active links within the system. In FIG. 19, oneembodiment of the link table 1912 is shown as a relational table,although any of a variety of different table implementations ispossible. Each active link is described by a row in the table, and eachrow includes the following fields: (1) a link_ID that uniquelyidentifies the link 1914; (2) the ID of the device that initiallyrequests the link 1916; (3) the ID of the device that is the target forthe request 1918; (4) the ID of the device that serves as the source ofinformation during link operation 1920; (5) the ID of the device thatserves as a sink for information during operation of the link 1922; (6)an indication of the type of link 1924 that, in turn, specifies theoperations that may occur over the link; and (7) an indication of thestate of the link 1926, described below. Although, in this discussion,links are generally considered unidirectional, the may also bebidirectional. In image-transfer applications, for example, informationmay be returned by a PC to a cell-phone to alter the rate, timing, andtype of images subsequently sent to the PC by the cell phone over alink.

FIG. 20 illustrates establishment of a link according to method andsystem embodiments of the present invention. In FIG. 20, actions for thelink-requesting device are shown in a first column 2002, actionsassociated with a link carried out by the server shown in a secondcolumn 2004, actions associated with the target of the link request areshown in a third column 2006, and the current state of the link is shownin column 2008. In a first step, the requesting device sends a linkrequest to the server indicating the target device for the link requestas well as the type of link requested 2010. Upon receiving the linkrequest, the server enters a new entry into the link table and forwardsthe link request to the target device 2012. At this point, the state ofthe link is “link requested” 2014. When the target device receives thelink request 2016, the target device may either return a message to theserver indicating that the target device declines their request 2018 ormay return a message to the server indicating that the target deviceaccepts the link request 2020. When the target device declines the linkrequest, the server receives the refusal and updates the link tableentry for the link request to indicate that the link has been refused2022, then forwarding the refusal to the requesting device. Therequesting device 2024 receives that refusal, and acknowledges receiptof the link refusal, at which point the state of the link becomes “nolink.” At an appropriate point in time, the entry for the link in thelink table is deleted. On the other hand, when the target device acceptsthe link, the server receives the acceptance, updates the link tableentry for the link, and forwards the acceptance to the requesting device2026. At this point, the state of the link is “link accepted.” Therequesting device receives the acceptance and acknowledges theacceptance to the server 2028, upon which the server updates the linkstatus to “link up” 2030. Thus, each link between devices must berequested by a device, and the link request must be accepted by thetarget device before the link is established. Messages and data are sentover the link in a two-part process. The source device sends messagesand data to the server by whatever communications medium interconnectsthe source device to the server, and the server forwards the messagesand data to the sink device by whatever communications medium and methodis used to transfer messages and data between the server and the sinkdevice. The link is therefore a virtual communications link implementedusing several underlying, dissimilar communications media and methodsand message and data routing by the server.

The secure connections between devices and the server are implemented byclients deployed to the device. FIG. 21 illustrates establishment of asecure link between a client running on a device and a server accordingto one embodiment of the present invention. In FIG. 21, client actionsare shown in a first column 2102 and service actions are shown in asecond column 2104. In one embodiment, the client is compiled with aserver authentication key, or, in other words, a public encryption key.In a first step, the client generates a public/private encryption-keypair as well as a random ID 2106. In step 2108, the client sends thepublic key of the encryption-key pair and the random ID to the server,encrypted using the server public key included in the client. In step2110, the server receives the encrypted public key and random ID anddecrypts the public key and random ID. If the server has seen the publickey/random ID pair in the past, as determined in step 2112, then theserver rejects the random ID generated by the client by sending arejection message in step 2114. When the client receives the rejectionmessage in 2116, the client can either retry secure-connectionestablishment or can consider establishment of the secure connection tothe server to have failed. When the public key/random ID pair has notbeen previously observed by the server, as determined in step 2112, theserver returns the public key and random ID pair to the client, in step2118, signing the message with the server's private server key. In step2120, the client receives the public key/random ID pair from the serverand verifies that the server digitally signed the message using theserver authentication key that was compiled with the client. The clientcan then use the random ID as the ID for the client in futurecommunications, in step 2122. In further communications with the server,the client can encrypt messages and data using the client's private key,and the server can decrypt the communications and data using the publickey transferred from the client to the server. Thus, communications overa secure connection between the device and the server cannot beintercepted or used by other devices, including even other devices towhich the device is linked by a virtual link discussed above withreference to FIGS. 18 and 19.

Establishment of a Multi-Tasking Environment on an Electronic, Hand-HeldDevice

As discussed above, many electronic hand-held devices, including manycell phones, lack the hardware and software to provide a robust,multi-tasking environment for execution of service applications. Ingeneral, service applications need to continuously or intermittentlyexecute on an electronic device, in order to field and respond to avariety of events associated with service provision, just as anoperating system needs to continually execute on a personal computer inorder to respond to user commands, incoming communications, and variousinterrupts and device-related events. On a single-processor system,continuous execution is simulated by running concurrently executingprocesses for small periods of time, or time slices, and interleavingthe time slices of different processes to provide the illusion that allexecuting processes are executing simultaneously. In other words,process execution is time-multiplexed on the processor. Method andsystem embodiments of the present invention establish a robust,multi-tasking computing environment on electronic hand-held devicesprior to deployment of, or as part of the process of deploying, serviceapplications to the electronic, hand-held devices. When the devices aresufficiently sophisticated to offer a robust, multi-tasking environment,method and system embodiments of the present invention avail themselvesof that functionality. However, in the more common case that a robust,multi-tasking environment is not provided by the electronic, hand-helddevice, method and system embodiments of the present invention usewhatever tools that are available within the electronic, hand-helddevice, the network interconnecting the electronic, hand-held devicewith a server, and the server to establish a computational environmentin which service applications can be deployed to, and execute on, theelectronic, hand-held device.

Applications running in multi-tasking environments commonly need amechanism for interprocess communication. In computer systems,interprocess communication is commonly implemented using shared memoryand/or interprocess messaging facilities. FIG. 22 illustrates a numberof the possible methods by which interprocess communication can beimplemented in an electronic, hand-held device in communication with aserver when the electronic, hand-held device does not offer nativeinterprocess communications, according to method and system embodimentsof the present invention. In FIG. 22, the electronic, hand-held deviceis shown as a first block 2202 and the server is shown as a second block2204. One way to achieve interprocess communication is to use localmemory 2206 within the device for storing messages and data forwarded byone process to another. For example, queues or mailboxes may beimplemented within the local memory to allow messages and data to bestored for subsequent delivery to other processes. Alternatively, incertain devices, facilities may be provided for general transmission andreception of messages. Those facilities may be used for transmittingmessages internally, between processes, when different processes can beidentified and addressed. For example, in certain systems, processes mayregister to receive messages and notification of incoming-messageevents. Alternatively, certain devices provide for remote procedurecalls (“RPCs”), which can be used to transfer data and messages betweenprocesses. When no such facilities are provided by the device, externalmessaging through the communications medium connecting the device to theserver may be employed for sending messages between processes running onthe device. For example, a process may run on the server for receivingmessages from the device and forwarding the received messages back totarget processes on the device. Although relatively inefficient, thislatter technique is nonetheless commonly available for most cell phonesand other communications devices.

Processes running in multi-tasking environments generally need to beable to persistently store data, so that the process can continue towork on a task over a number of time slices and periods of quiescence.FIG. 23 displays various methods for implementing persistent datastorage on an electronic, hand-held device, when persistent data storagefacilities are not explicitly provided by the device according to methodand system embodiments of the present invention. First, local memory2302 within the device can be partitioned among processes by memoryallocation or by convention. Alternatively, internal messagingfacilities 2304 may be used by a process to send messages to itself thatinclude data, for subsequent access, that the process may need to accessduring subsequent time slices. In other words, a process may include thedata needed to be persistently stored in the message and send themessage to itself. The internal messaging service receives the messageand queues the message for delivery to the process. The process mayenter a quiescent state due, for example, to the process relinquishingcontrol of processing facilities to another process upon expiration ofthe process's time slice. Later, when the process reawakens, the processmay access the queued message to recover the data. When internalmessaging facilities are not provided on the device, a process may useexternal messaging 2306 to store data within the server 2204. The datamay be stored within messaging queues 2308-2309, or may be stored inmemory areas 2310 apart from messaging queues.

Processes running within multi-tasking systems in a single-processorenvironment need to be able to quiesce, or relinquish the processor, andthen be automatically reawakened at a later time to continue processingtasks. FIG. 24 illustrates a number of mechanisms that can be used forlaunching and reawakening processes within an electronic, hand-helddevice according to method and system embodiments of the presentinvention. First, the device may include a native operating system orcontrol program 2402 that provides a multi-tasking environment,including the ability to quiesce and reawaken processes in order toprovide concurrent processing for a number of processes within thedevice. When the device does not include such a native operating systemor control program, the device may include a timer facility 2404 thatallows a process to set a timer that, upon expiration, generates anevent that awakens or reawakens the process. Processes can cooperate toimplement a multi-tasking environment by setting timers at the beginningof a current execution to a reasonable time-slice value. When the timerexpires, the process is notified, and relinquishes control of theprocessor to another process. Alternatively, the process can set a timerto a more distant, future time corresponding to the beginning of areasonable next time slice for the process, so that other processes mayexecute in the interim until the process is reawakened by expiration ofthe timer. Thus, timers can be used in many different ways to implementa multi-tasking environment among cooperating processes. Similarly, adevice may provide for event mechanisms 2406 that allow processes to beawakened or reawakened on occurrence of different types of events. Thus,a process may register to be awakened by an event elicited by receptionby the device of a particular type of message from the server, and theserver can implement multi-tasking by continuously reawakening processesat reasonable intervals. This can be implemented in a watchdog ormonitor program 2408 running within the server. Another technique may beto modify an existing application native to the device 2410 to launchprocesses at particular times using an event mechanism or timerfacility, or a special scheduling client or application may be installedon the device in order to launch and quiesce processes in order toimplement a multi-tasking environment. When no other alternative isavailable, processes may execute on the server 2412 in the server'smulti-tasking environment and exchange data with a device through thecommunications medium connecting the device of the server in order tosimulate a multi-tasking environment on the device.

FIG. 25 is a control-flow diagram illustrating process behavior on anelectronic, hand-held device for processes that cooperate to implement arobust, multi-tasking environment according to method and systemembodiments of the present invention. FIG. 25 illustrates processactivities during a single time slice of process operation. In step2502, the process awakens by any of the methods described above withreference to FIG. 24. In step 2504, the process employs any of a varietyof techniques to monitor the physical environment of the hand-helddevice to determine whether or not the process should continueoperating, or operate at a reduced level of resource usage. In certainsystems, the process may use device-supplied functions for determining,for example, the power level of the device, communications state of thedevice, and other such device states and operational characteristics.Alternatively, a process may indirectly detect power states andcommunication states by monitoring the rate at which tasks are executed,noting various features currently available to processes running on thedevice, and other such characteristics of the device. If, as determinedin step 2506, the current state of the device is not conducive forprocess execution, the process may configure the device, server, ordevice and server for reawakening the process at a later time, in step2508, and then quiesce, or relinquish control of the processor withinthe device, in step 2510. Otherwise, if the state of the device is suchthat the process needs to use fewer computational resources, or if thestate of the device is such that the process may safely use additionalcomputational resources, as determined in step 2512, then the processmay modify the length of the current time slice according to thedetected device state in step 2514. Next, in step 2516, the processrecovers persistent data needed by the process to continue execution byany of the methods discussed above with reference to FIG. 23. Theprocess can then undertake execution of tasks in the loop of steps2517-2518 until either a timer expires or the process detects, by othermeans, that its current time slice has ended. When the time slice hasended, the process configures the device, the device and the server, orthe server to restart the process at a subsequent time, in step 2520, byany of the methods discussed above with reference to FIG. 24, and thenquiesces, in step 2510. Thus, by executing for a reasonable amount oftime, and then relinquishing the processor, processes running within anelectronic, hand-held device can cooperate to achieve a multi-taskingenvironment in which processes can continue to execute for long periodsof time by interleaving their execution with other processes. Moreover,processes can detect certain device states or characteristics thatrequire processes to relinquish the processor prior to the defaulttime-out period, such as low power conditions, or, in the case of cellphones, incoming or outgoing voice communications.

A Digital-Image Service Application that Represents One Embodiment ofthe Present Invention

One exemplary service application that can be deployed and executedusing the above-described component methods and systems of the presentinvention is next described. The exemplary service application allowsfor digital images captured by cell phone to be easily, securely, andseamlessly transferred from the cell phone to the cell phone user'spersonal computer, other personal computers, or third party systems.FIG. 26 illustrates a digital-image-transfer service application thatrepresents one embodiment of the present invention. As shown in FIG. 26,digital images captured and stored on a source device 2602 aretransferred via the virtual communications medium or network 2604provided by method and system embodiments of the present invention to aserver 2608, where the digital images may be stored in server memory2610 and/or forwarded to any of various target devices 2612 or to other,remote entities 2614. The digital-image-transfer service application canbe considered to be distributed across the source device 2602, theserver 2608, and the target device 2612. FIG. 27 is a control-flowdiagram illustrating operation of the source-device portion of thedigital-image-transfer service application. The service application runscontinuously or intermittently on the source device using themulti-tasking environment discussed above in the previous subsection. Instep 2702, the service application determines whether any new data, suchas a digital image, is available for transfer. If not, the applicationcan return, or quiesce in step 2704. Otherwise, in step 2706, theapplication determines whether the newly available data should be storedlocally or transferred to the server. If the data should be storedlocally, then the application stores the data for later retrieval, instep 2708, and quiesces. Otherwise, in step 2710, the applicationdetermines whether or not the data can and should be specificallyaddressed to one or more target devices. If so, then in step 2712, theapplication includes target addresses by, for example, listing thetarget addresses in a message header. Next, in step 2714, theapplication determines whether any additional processing may be neededand, if so, processes the data in step 2716. For example, in the case ofdigital images, the application may crop the image, decrease theresolution of the image, quantize the image, decrease the number ofcolors used in the image, or compress the image. Then, in step 2718, theapplication queues the image for transmission to the server. In step2720, the application determines whether any previously stored datashould also be sent to the server and, if so, retrieves the stored datain step 2722 and returns to step 2710 to send the retrieved data.Finally, in step 2724, the service application undertakes transmissionof data to the server.

FIGS. 28 and 29 illustrate the server portion of the digital-imagetransfer service that represents one embodiment of the presentinvention. In step 2802, the application determines whether any new datahas been received from source devices. If not, the application canquiesce, in step 2804. Otherwise in nested for-loops that begin withsteps 2806 and 2808, the server-side application processes each receiveddata item with respect to each target device listed for the data item.In step 2810, the application determines whether any processing isneeded for the data item and, if so, processes the data item in step2812. As discussed above, this processing may involve cropping,pressing, or otherwise changing and manipulating the digital image forefficient transfer or for compatibility with target-device capabilities.If the target device is currently available, as determined in step 2814,then the data or digital-image is queued for delivery to the target instep 2816. If the digital image needs to also be locally stored withinthe server for a period of time, as determined in step 2818, then if thedigital image is not already locally stored, the application stores thedigital image in step 2820. If the target is not available, asdetermined in step 2814, the digital image is locally stored in step2822, if it is not already locally stored, and a task is queued to alocal queue within the server, in step 2824, to direct subsequentdelivery of the data to the target at a later time. Queuing of the datamay involve setting a timer.

FIG. 29 illustrates a handler associated with the server-sidedigital-image transfer application. The handler waits, in step 2902, fora next event to occur. If the next event is expiration of a queueddelivery timer, as determined in step 2904, then the handler identifiesthe data associated with the timer and transmits the data to the targetdevice, in step 2906, when possible. If the item is no longer needed, asdetermined in step 2908, then the handler deletes the data item, such asa digital image, from local storage in step 2910. Otherwise, if a failedtransfer has been detected, in step 2912, such as by a message sent froma target device to the server indicating failed transfer, then, in step2914, the handler can queue the data item for subsequent transfer to thetarget. A default handler 2916 handles additional types of events.

FIG. 30 is a control-flow diagram illustrating the target-device portionof the digital-image transfer service application that represents oneembodiment of the present invention. In step 3002, the applicationdetermines whether new data, such as a digital image, has been received.If not, then the process can return or quiesce, in step 3004. Otherwise,the application extracts metadata from the received data-bearing messageor messages, in step 3006. If processing of the received data is needed,as determined in step 3008, the data is processed in step 3010.Otherwise, in the for-loop comprising steps 3012-3015, the applicationstores the data at target locations within the target device, when thedata meets any of various criteria for storage. Thus, for example, thetarget may elect to store only certain images, rather than all imagesreceived from the source device depending on the frequency of receptionof images, time of day, or other such criteria.

Although the present invention has been described in terms of particularembodiments, it is not intended that the invention be limited to theseembodiments. Modifications within the spirit of the invention will beapparent to those skilled in the art. For example, any of a huge numberof different types of service applications can be implemented accordingto the method and system embodiments of the present invention. Serviceapplications may be used for transferring data, collecting data,launching display-generating applications, conducting periodic tasks ofa wide variety of natures, and many other such types of tasks andactivities. Such applications may be implemented using any of a widevariety of different programming languages, control structures, modularorganizations, data structures, variables, and other such programmingcharacteristics. The component method and system embodiments of thepresent invention can be tailored to any particular device and serverembodiment, including a wide variety of different types ofcommunications media, protocols, and systems by which devices interactwith each other and communicate with the server. Implementation of thevirtual communications medium or network can be tailored to any of alarge number of different types of devices, servers, and device/serverinterconnection environments. In certain systems, user interfaces may bepresented by deployed service applications to allow users to control,acknowledge, and grant permission for operation of the serviceapplications. Service applications may additionally be controlled byout-of-band messages exchanged between devices, such as between cellphones through the phone network. Although multitasking environments arefavored for service-application execution, service applications may,when it is not possible to create multitasking environments onparticular device, nevertheless be executed, at worst by repeatedlyretransmitting the service application to device, as needed.

Upon installation on the phone, the image-transfer phone software isgenerally configured with the address of the fileserver, plus anyadditional configuration parameters necessary for the image-transferphone software to operate. The image-transfer software may come with aset of options predefined, including the location of the fileserver aswell as an FTP account and password for that user.

The image-transfer phone software may be automatically started when theuser powers on the phone. After turning on the phone, the user cangenerate an image, for example by taking a picture with thecamera-equipped phone. When the picture is taken, it is usually writtento the file system located on the phone's internal persistent memory(internal or on a memory card). The image-transfer phone softwarerunning on the camera becomes aware of the new image, for example byregularly polling the file system on the camera-equipped phone lookingfor new images. When a new image is detected, the Photosync Phone Clientsoftware opens its connection to the fileserver over one of the networkaccess systems available on the phone.

After opening the connection, for example via FTP, the image-transferphone software transfers the image onto the fileserver. The file may bestored in a directory named by the camera-equipped phone's phone number(by storing the images in a unique directory, there are no collisionsbetween the files uploaded by one camera-equipped phone and the filesuploaded by another camera-equipped phone). When the transfer iscomplete, the file may be deleted from the camera-equipped phone,leaving room for more images. Images uploaded onto the server may bepersisted until deleted by the PC client software.

On both the server and the client, unique filenames can preventcollisions or race conditions resulting in data loss. To provide this,the image-transfer phone software can upload the image file with a newname. The file name of the new file created on the fileserver can becreated by concatenating the following text strings:

-   -   The original image file name as recorded on the phone    -   The precise date and time of the photo's creation,    -   An additional index (like a “(2)” or “_(—)2”) to account for        existing duplicate files    -   The string “.transfer”

The final suffix string “.transfer” may be used to indicate to any otherclients on the fileserver that the file is still being uploaded by theclient. When the file is completely uploaded, the file may be renamed onthe file server by the image-transfer phone software to remove the“.transfer” suffix.

The personal-computer image-transfer software is then able to downloadthe files. The personal-computer image-transfer software may be startedwhen the PC is powered on, or when the user is logged into the PC. Todownload the files, the personal-computer image-transfer softwareconnects to the fileserver, for example via FTP. The personal-computerimage-transfer software need not be running simultaneously with thearrival of the photos on the server, but it can be. Thepersonal-computer image-transfer software typically polls the fileserver(FIG. 1, “B”) periodically, checking for new images in its configureddirectory, named by the camera-equipped phone's phone number.

When the FTP file upload from the image-transfer phone software iscomplete, and the file renamed to remove the “.transfer” suffix, thepersonal-computer image-transfer software can assert the file hascompleted transfer to the file server and can begin download of the fileto the PC. The personal-computer image-transfer software may downloadthe file using standard binary FTP protocol (FIG. 1, “C”), and thenplace it in a known spot on the user's hard drive, for example theuser's My Pictures folder. It may then delete it from the fileserver.

The above describes only one possible implementation. Many alternativeimplementations are possible:

-   -   Data files other than images can be transferred by this system.        In any case in this document in which images are described, data        other than photos may be substituted. Examples include videos,        text notes, or address book records. Note that in this document        “photos”, “images”, etc. may be described, but any type of file        may be used.    -   Image transfer may be in made in either direction. The PC can        upload photos to 30 the fileserver, and the image-transfer phone        software can download them.

Consequently, any time a image-transfer phone software andpersonal-computer image-transfer software are specified in thisdocument, the scenario may be reversed. Additionally, transfers may bemade from personal-computer image-transfer software to personal-computerimage-transfer software or image-transfer phone software toimage-transfer phone software. Consequently, the personal-computerimage-transfer software and image-transfer phone software areinterchangeable.

-   -   There are different ways the linkage between the image-transfer        phone software and personal-computer image-transfer software can        be configured or declared by the user. For example, the pairing        between the image-transfer phone software and the        personal-computer image-transfer software could be contingent on        the user entering a passcode into both the phone and the client,        thereby proving that they have physical access to both.    -   The linkage between the image-transfer phone software and        personal-computer image-transfer software may be automatically        configured without specific action from the user. Instead of        forcing the user to indicate the pairing between the        image-transfer phone software and personal-computer        image-transfer software, the user may download software for the        phone and client that have been paired before delivery. For        example, the user might enter their phone number on a website.        The website would then add the user's phone number to the phone        software installer and then send it directly to the phone, ready        for use. Likewise, it would add the user's phone number to the        client software installer and then initiate a download of it.    -   The file to be transferred may be generated from different        programs or hardware. The standard camera-equipped phone        software may be used to generate an image, or the image-transfer        phone software might cause the onboard camera to take a picture        to generate an image, or a third party program may generate an        image from code or from the camera or another hardware device.        Files may come from any conceivable source, including user        input, additional hardware, or transfers from other devices.    -   The file might not be written to persistent storage on the        phone. For example, pictures may be transferred directly from        the camera chip to the server, and never written to local phone        storage.    -   Polling may be replaced with notification. Instead of requiring        the image-transfer phone software to poll the phone's file        system to detect a new image, for example, an event, interrupt,        or message may be generated by the software that creates the        file (e.g., the onboard camera application). This would trigger        the file transfer to begin.    -   The image-transfer phone software or personal-computer        image-transfer software may be turned on or off by a variety of        means. It could be controlled by the phone's ringing profile,        explicit request by the user, or any other method that is used        to control software startup/ending.    -   The image-transfer phone software, personal-computer        image-transfer software, and fileserver may delete files        according to any policy. For example, the image-transfer phone        software may delete pictures as soon as they are taken, or leave        them on the phone. The personal-computer image-transfer software        may delete files smaller/larger than a certain size. The server        may delete photos after the personal-computer image-transfer        software has downloaded them, or it may wait for a deletion        instruction from the personal-computer image-transfer software,        or it may leave them in place for 30 days so a user could view        them with a web browser in the interim.    -   The image-transfer phone software may store files on different        storage media. For example, the camera-equipped phone may be        physically attached to a third party storage device, or may be        mapping a remote network storage device as local phone storage.        In either event, the files could still be uploaded to the        fileserver. Alternately, the device might act as the fileserver.    -   The image-transfer phone software might be connected to the        fileserver through alternate means. For example, the phone might        be connected by USB cable or by an 802.11 network connection,        instead of by the phone data network.    -   The fileserver might not write the files to disk. For example,        the files may be kept in memory in part, transfer parts of the        file to the client as is possible, or may be kept in memory        wholly, with the system functioning identically as before.    -   The usage of a unique directory may be made transparent to the        software. This may be accomplished by configuring the FTP user        login to use a specific directory as its root.    -   Multiple clients can transfer images to each other. One or more        image-transfer phone softwares belonging to one or more users        may transfer images to one or more personal-computer        image-transfer softwares belong to one or more users (which may        or may not be the same set of users as the first).    -   Multiple servers may be used. A variety of servers can        accomplish load balancing, enhanced security, and other goals.        All servers may serve a single transaction, or each transaction        may be assigned to one or more servers, or any other such        combination. Servers may be assigned based on any criteria, such        as geographical proximity, network proximity, type of file being        transferred, or identity of user.    -   Transfers could be only file metadata, not the entire file. The        image-transfer phone software may upload information about files        (e.g., filenames) to the fileserver instead of the actual files.        The personal-computer image-transfer software can then select        pictures to download, either programmatically or with end-user        input.    -   The personal-computer image-transfer software may deposit the        files in one or more different locations on the PC. For example,        it might both place them in the My Pictures folder and archive        them to tape backup.    -   The personal-computer image-transfer software may signal the        arrival of files to the user. An icon on the screen may change        appearance, a dialog box may display a thumbnail of the file, or        a sound may be played, for example.    -   A variety of coping strategies exist when the fileserver goes        offline. The image-transfer phone software may resend later,        store the files without resending them, or delete the files, for        example. The personal-computer image-transfer software may        notify the user or not, retry download or not, or fail over to        another server, for example.    -   A variety of coping strategies exist when the personal-computer        image-transfer software goes offline. The server may hold the        files indefinitely or for a finite length of time before        deleting them. The server may transfer them to an alternate        client. The server may notify the user.    -   Roundtrip confirmation is possible. The image-transfer phone        software may receive acknowledgement of a successful        transaction. For example, when the file has been successfully        written the personal-computer image-transfer software and its        checksum verified, the personal-computer image-transfer software        may inform the fileserver, which would in turn notify the        image-transfer phone software. The image-transfer phone software        could then choose to, for example, delete the file, knowing it        had been safely transferred.    -   Files may be transferred to a third party server instead of the        fileserver or the personal-computer image-transfer software. For        example, photos might be transferred to an internet-based        third-party photo hosting service. The transfer could occur        directly from the phone, bypassing the fileserver; it could        occur from the fileserver, bypassing the personal-computer        image-transfer software, or it could occur once the files had        been sent to the personal-computer image-transfer software, as        examples.    -   Any part of the system can configure any other. For example, a        user could configure the image-transfer phone software,        fileserver, or personal-computer image-transfer software        behavior from the image-transfer phone software, the fileserver        (via, for example, a web page), or from the personal-computer        image-transfer software. This would allow the user to, for        example, indicate from her phone that she intends the files to        be stored in the “My Pictures” folder on her PC.    -   Files transferred may be routed selectively. For example, the        files can be routed to different locations based on the file        type as determined by the three letter file extension, MIME        type, or other metadata. This can happen at the image-transfer        phone software, fileserver, or personal-computer image-transfer        software level.    -   Files may be acted on immediately. Files may be routed to        specific applications for immediate handling, instead of being        saved to disk. For example, a sound might be routed to a media        player for immediate playback when it is received at the        personal-computer image-transfer software.    -   Different mechanisms may be used to track the state of the        transfer. Instead of changing the file name to indicate the        state of the file transfer, a secondary file may record the        state of the transfer process, or an altogether separate        communication channel. The phone, fileserver, and/or        personal-computer image-transfer software may be used to send        transfer status. It is also possible to not record transfer        status at all, and have the PC transfer whatever is available        immediately, or to have the personal-computer image-transfer        software infer when transfer is done (for example when less bits        are transferred than the stated JPG image size, the file is not        complete).    -   File transfer may occur before the file has completely arrived        at the phone or file server. For example, a video might be        streamed over the network instead of storing it locally, or it        might be stored in part locally, possibly with the local data        deleted as it is sent off to the fileserver I personal-computer        image-transfer software.    -   The system may transfer files in discrete parts. The        image-transfer phone software may transfer an image file in        segments, to be reassembled into the complete image file, either        on the file server or on the personal-computer image-transfer        software.    -   The fileserver may push the images to the client without being        requested. The personal-computer image-transfer software may        maintain a connection to the file server, over which the        fileserver pushes files as they arrive on the system. For        example, the personal-computer image-transfer software's drive        might simply be mapped to the fileserver so it can write the        files to it using standard network protocols.    -   The image-transfer phone software may be polled by the file        server to request photos. The Photo PC may maintain an open        connection to the file server, over which the file server may        send the request to send photos present on the phone.    -   The image-transfer phone software may send photos to the        fileserver which were created before the image-transfer phone        software was started. Before the image-transfer phone software        is initialized/installed, files may be created (e.g., pictures        taken) by the user. These are stored in the normal fashion. When        the image-transfer phone software is installed/initialized,        these files can be transferred. Similarly, files queued up on        the fileserver may be transferred to a new or newly-active        personal-computer image-transfer software.    -   Different network protocols and systems may be used to transmit        the data. The server may use something other than FTP as the        file transfer protocol for transmitting files to the client. Any        protocol that allows the transfer of files would be sufficient.        For example, the phone may send the picture via the MMS        protocol. In this case, the server would receive the MMS        message, decode the attachment, and then proceed as if it had        been conventionally uploaded. Or, the files may be sent as        E-mail, in which case the server can receive and forward email        as per a standard e-mail server.    -   A proprietary piece of software may serve as the file server.        The server may be running specialized software that does not        allow the client or the phone to have direct access to its file        system, as FTP does. It may have specialized software that        supports any of the following features:    -   It can recognize authorized image-transfer phone softwares, for        example using a proprietary interface to retrieve a unique        identifier from the phone and verifying the validity of the        identifier against a master lookup table.    -   It can recognize authorized software, for example by exchanging        secret keys that are stored in the program.    -   When new image-transfer phone softwares or personal-computer        image-transfer softwares connect to the server, it may create a        new user-account for the user of these devices and/or prompt for        an existing user account (including username and password) to        properly associate the devices.    -   When the personal-computer image-transfer software first        attempts to specify the image-transfer phone software that it        wishes to be “paired” with, the fileserver may issue a        verification request to the image-transfer phone software, and        only allow the pairing if the request is successful. For        example, it may transmit a message to the image-transfer phone        software via SMS asking the user to agree to the pairing. The        user agrees by opening a link contained in the SMS message in        the phone's browser. That link leads the phone back to the        fileserver, verifying for the server that the pairing will be        allowed.    -   The server may “pass through” the data directly to the client,        without ever storing it.    -   The connection may be additionally secured. The image-transfer        phone software software may allow the user to specify a        password, which the fileserver software would require of any        personal-computer image-transfer softwares before allowing a        successful connection. Various security and cryptographic        systems may be used to secure the connection further.    -   A fee may be charged for some or all aspects of this service.        Fees could be monthly, per-kb, or using any other pricing        scheme. Additional fees may be charged by service providers, for        example bandwidth charges billed through the phone carrier.    -   Files on the server may be accessible through other means. The        user may be able to access the photos while they reside on the        server using an alternate means, such as a web browser.    -   Data may be transformed at any point in the transfer process.        The image-transfer phone software, fileserver, or        personal-computer image-transfer software may encode, decode, or        otherwise modify the file automatically. For example, the        image-transfer phone software might lower the resolution of the        picture before transferring it to the fileserver, and the        fileserver might re-encode the picture to a file format        compatible with the personal-computer image-transfer software        before transferring it to the personal-computer image-transfer        software.    -   Additional actions may occur as a result of the file transfers.        For example, the file server may record how often files are        delivered by a user, how often they are downloaded by the        client, or how large the images are.    -   The image-transfer phone software and personal-computer        image-transfer softwares may send diagnostic information to the        fileservers. If a client on either device encounters an error or        exception, it may send a message to the fileserver (in the form        a file in the image directory, or by an altogether separate        communication mechanism).    -   The image-transfer phone software, fileserver, and        personal-computer image-transfer software may update themselves.        For example, the image-transfer phone software might poll the        fileserver to find a new version of itself, and if found,        download and install it.    -   The user may configure which personal-computer image-transfer        softwares receive files. For example, a user might indicate to        the image-transfer phone software that a particular file is to        go to a home PC instead of the default work PC.

The foregoing description, for purposes of explanation, used specificnomenclature to provide a thorough understanding of the invention.However, it will be apparent to one skilled in the art that the specificdetails are not required in order to practice the invention. Theforegoing descriptions of specific embodiments of the present inventionare presented for purpose of illustration and description. They are notintended to be exhaustive or to limit the invention to the precise formsdisclosed. Obviously many modifications and variations are possible inview of the above teachings. The embodiments are shown and described inorder to best explain the principles of the invention and its practicalapplications, to thereby enable others skilled in the art to bestutilize the invention and various embodiments with various modificationsas are suited to the particular use contemplated. It is intended thatthe scope of the invention be defined by the following claims and theirequivalents.

1. A method for providing a service-application-execution environment ina heterogeneous computing environment comprising electronic, hand-helddevices, a server, and personal computers interconnected by multiplecommunications media and networks, the method comprising: deploying adynamically created device-side service application on a plurality ofelectronic, hand-held devices, the device-side service applicationspecifically tailored for deployment to the electronic, hand-held deviceand preconfigured to allow for communications with the server and, whenmultitasking facilities are not available to the device-side serviceapplication on the electronic, hand-held device, employing features andfunctions provided by one or more of the electronic, hand-held device,server, and a network to establish a multitasking environment on theelectronic, hand-held device; and establishing secure connectionsbetween each electronic, hand-held device and the server.
 2. The methodof claim 1 wherein employing features and functions provided by one ormore of the electronic, hand-held device, server, and a network toestablish a multitasking environment on the electronic, hand-held devicefurther includes: using features and functions provided by one or moreof the electronic, hand-held device, server, and a network to providefor inter-process communication for processes associated with theelectronic, hand-held device; using features and functions provided byone or more of the electronic, hand-held device, server, and a networkto provide for persistent data storage for processes associated with theelectronic, hand-held device; and using features and functions providedby one or more of the electronic, hand-held device, server, and anetwork to provide for launching and reawakening processes associatedwith the electronic, hand-held device.
 3. The method of claim 2 whereinfeatures and functions used to provide for inter process communicationinclude one or more of: an internal messaging facility within theelectronic, hand-held device; network messages; memory local to theelectronic, hand-held device; and a remote-procedure-call facilitywithin the electronic, hand-held device.
 4. The method of claim 2wherein features and functions used to provide for persistent datastorage include one or more of: an internal messaging facility withinthe electronic, hand-held device; network messages; memory local to theelectronic, hand-held device; server memory; and server message queues.5. The method of claim 2 wherein features and functions used to providefor launching and reawakening processes include one or more of: anoperating system or control program native to the electronic, hand-helddevice; an event handling facility within the electronic, hand-helddevice; a scheduling and monitoring process running within theelectronic, hand-held device; an timer facility within the electronic,hand-held device; a monitor program running on the server; andsimulation by execution of processes on the server.
 6. The method ofclaim 1 wherein establishing a secure connection between an electronic,hand-held device and the sewer further includes: generating apublic/private encryption-key pair by a client running on theelectronic, hand-held device; generating an identifier by the clientrunning on the electronic, hand-held device; using a server public keyincluded in the client to encrypt the generated public key andidentifier and sending the encrypted generated public key and identifierto the server; receiving from the server an indication of whether or notthe public key and identifier are accepted for communications, theindication digitally signed by the server; using the server public keyincluded in the client to verify that the indication was sent by theserver; and when the indication indicates acceptance of the generatedpublic key and identifier, using the identifier as a client and/ordevice identifier for subsequent communications via the secureconnection and using the public/private encryption-key pair to encryptand decrypt messages and data exchanged with the server.
 7. Adigital-image transfer service application running within aservice-application execution environment created by the method of claim1, the digital-image transfer service application transferring digitalimages captured by a digital camera included in a cell phone through theserver to user device.
 8. The method of claim 1 wherein the dynamicallycreated device-side service application includes credentials tailoredfor each of the plurality of electronic, hand held devices, saidcredentials configured to facilitate communication between the pluralityof electronic, hand held devices and a server.
 9. An apparatus forproviding a service-application-execution environment in a heterogeneouscomputing environment comprising electronic, hand-held devices, aserver, and personal computers interconnected by multiple communicationsmedia and networks, the apparatus comprising: means for deploying adynamically created device-side service application on a plurality ofelectronic, hand-held devices, the device-side service applicationspecifically tailored for deployment to the electronic, hand-held deviceand preconfigured to allow for communications with the server and, whenmultitasking facilities are not available to the device-side serviceapplication on the electronic, hand-held device, means for employingfeatures and functions provided by one or more of the electronic,hand-held device, server, and a network to establish a multitaskingenvironment on the electronic, hand-held device; and means forestablishing secure connections between each electronic, hand-helddevice and the server.
 10. The apparatus of claim 9 wherein the meansfor employing features and functions provided by one or more of theelectronic, hand-held device, server, and a network to establish amultitasking environment on the electronic, hand-held device furtherincludes: means for using features and functions provided by one or moreof the electronic, hand-held device, server, and a network to providefor inter-process communication for processes associated with theelectronic, hand-held device; means for using features and functionsprovided by one or more of the electronic, hand-held device, server, anda network to provide for persistent data storage for processesassociated with the electronic, hand-held device; and means for usingfeatures and functions provided by one or more of the electronic,hand-held device, server, and a network to provide for launching andreawakening processes associated with the electronic, hand-held device.11. The apparatus of claim 10 wherein features and functions used toprovide for inter process communication include one or more of: aninternal messaging facility within the electronic, hand-held device;network messages; memory local to the electronic, hand-held device; anda remote-procedure-call facility within the electronic, hand-helddevice.
 12. The apparatus of claim 10 wherein features and functionsused to provide for persistent data storage include one or more of: aninternal messaging facility within the electronic, hand-held device;network messages; memory local to the electronic, hand-held device;server memory; and server message queues.
 13. The apparatus of claim 10wherein features and functions used to provide for launching andreawakening processes include one or more of: an operating system orcontrol program native to the electronic, hand-held device; an eventhandling facility within the electronic, hand-held device; a schedulingand monitoring process running within the electronic, hand-held device;an timer facility within the electronic, hand-held device; a monitorprogram running on the server; and simulation by execution of processeson the server.
 14. The apparatus of claim 9 wherein the means forestablishing a secure connection between an electronic, hand-held deviceand the sewer further includes: means for generating a public/privateencryption-key pair by a client running on the electronic, hand-helddevice; means for generating an identifier by the client running on theelectronic, hand-held device; using a server public key included in theclient to encrypt the generated public key and identifier and sendingthe encrypted generated public key and identifier to the server;receiving from the server an indication of whether or not the public keyand identifier are accepted for communications, the indication digitallysigned by the server; means for using the server public key included inthe client to verify that the indication was sent by the server; andwhen the indication indicates acceptance of the generated public key andidentifier, means for using the identifier as a client and/or deviceidentifier for subsequent communications via the secure connection andusing the public/private encryption-key pair to encrypt and decryptmessages and data exchanged with the server.
 15. A digital-imagetransfer service application running within a service-applicationexecution environment created by the apparatus of claim 9, wherein thedigital-image transfer service application is configured to transferdigital images captured by a digital camera included in a cell phonethrough the server to user device.
 16. The apparatus of claim 9 whereinthe dynamically created device-side service application includescredentials tailored for each of the plurality of electronic, hand helddevices, said credentials configured to facilitate communication betweenthe plurality of electronic, hand held devices and a server.
 17. Adevice for providing a service-application-execution environment in aheterogeneous computing environment comprising electronic, hand-helddevices, a server, and personal computers interconnected by multiplecommunications media and networks, the device comprising: a processorfor deploying a dynamically created device-side service application on aplurality of electronic, hand-held devices, the device-side serviceapplication specifically tailored for deployment to the electronic,hand-held device and preconfigured to allow for communications with theserver and, when multitasking facilities are not available to thedevice-side service application on the electronic, hand-held device,employing features and functions provided by one or more of theelectronic, hand-held device, server, and a network to establish amultitasking environment on the electronic, hand-held device; and aprocessor for establishing secure connections between each electronic,hand-held device and the server.
 18. The device of claim 17 wherein thedynamically created device-side service application includes credentialstailored for each of the plurality of electronic, hand held devices,said credentials configured to facilitate communication between theplurality of electronic, hand held devices and a server.